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When  providing  engineering  services,  the  U.S. 
Army  Corps  of  Engineers  must  compiy  with 
certain  pubiic  iaws  and  regulations  by  using  the 
traditional  project  delivery  process.  This  pro¬ 
cess  is  a  fragmented  set  of  sequential  phases, 
each  with  its  own  requirements,  creating  a  lack 
of  integration  and  coordination  among  project 
participants,  both  within  a  project  and  across 
many  projects.  Consequently,  knowledge  and 
experience  gained  from  one  phase  or  project  in 
a  civil  works  organization  are  usually  inade¬ 
quately  transferred,  or  not  transferred  at  all,  to 
other  phases  or  other  projects.  Another 
problem  that  many  civil  works  organizations 
are  facing  is  the  loss  of  many  veteran  person¬ 
nel  who  have  a  vast  amount  of  knowledge  and 
experience  in  the  civil  works  organization. 

The  implementation  of  an  automated  system 
that  can  capture,  store,  and  share  the  know¬ 
ledge  and  experience  of  all  project  participants. 
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throughout  all  phases  of  the  project  life  cycle, 
will  help  reduce  the  problem  caused  by  a  frag¬ 
mented  delivery  process.  This  system  can 
also  capture  the  experiential  knowledge  of 
veteran  personnel  before  they  leave  the 
organization. 

This  report  describes  the  development  and 
implementation  of  such  a  system,  the  Organi¬ 
zational  Knowledge  Bank  (OKBank).  The 
OKBank  system  takes  the  advantages  of  the 
world  wide  web  and  other  relational  software 
programs  in  effectively  capturing,  processing, 
and  disseminating  organizational  knowledge. 
The  knowledge  base  in  the  OKBank  contains 
not  only  organizational  experiences  such  as 
lessons  learned,  good  work  practices,  and 
success  stories,  but  also  include  geo¬ 
graphically  oriented  project  information. 
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1  Introduction 


Background 

The  mission  of  the  U.S.  Army  Corps  of  Engineers  is  to  provide  quality,  responsive 
engineering  service  to  the  Army  and  the  Nation.  The  Corps  plans,  designs, 
builds,  and  operates  water  resources  and  other  Civil  Works  projects  to  provide  to 
the  taxpayer  a  variety  of  benefits,  including  flood  damage  reduction,  navigation, 
and  environmental  restoration.  They  also  provide  military  construction  for  the 
Army  and  Air  Force  and  provide  design  and  Construction  management  support 
for  other  Federal  agencies. 

Under  the  Civil  Works  Program,  the  Corps  operates  and  maintains  almost  300 
deep  draft  harbors,  275  locks,  and  12  thousand  miles  of  navigable  waterway.  The 
383  lakes  and  8,500  miles  of  levees  managed  by  the  Corps  prevent  an  estimated 
$26.8  billion  in  potential  flood  damages  annually.  Since  the  Corps  flood  control 
program  began  in  1928,  the  Corps  estimates  that  its  projects  have  prevented  a 
total  of  $319  billion  in  flood  damages  at  a  Federal  cost  of  about  $37.5  billion, 
which  is  $8.51  in  deimages  prevented  for  each  dollar  expended.  The  Corps 
operates  75  hydropower  facilities,  providing  25  percent  of  the  nation's 
hydropower  capacity.  Last  year  more  than  $500  million  was  spent  on 
environmental  activities  imder  the  Civil  Works  program,  including  major 
restoration  efforts  in  the  Everglades  and  the  Pacific  Northwest  and  in  smaller 
ecosystem  projects.  The  Corps  is  the  nation's  largest  provider  of  water-based 
recreation,  with  more  than  4,000  recreation  sites  hosting  377  million  visits  in 
1997. 

In  the  process  of  delivering  these  civil  works  projects,  the  Corps  has  to  comply 
with  certain  public  laws  and  regulations,  which  generally  require  civil  works 
projects  be  delivered  using  the  traditional  process.  The  traditional  project 
delivery  process  comprises  a  fragmented  set  of  sequential  phases,  each  with  its 
own  requirements  (Fig^e  1).  This  fragmented  delivery  process  creates  a  lack  of 
integration  and  coordination  among  project  participants,  both  internally  within  a 
project  and  externally  across  many  projects.  Consequently,  knowledge  and 
experience  gained  from  one  phase  or  one  project  in  a  civil  works  organization  are 
usually  retained  exclusively  as  personal  property  and  are  inadequately 
transferred,  or  not  transferred  at  all,  to  other  phases  or  other  projects. 
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Figure  1.  Traditional  capital  project  delivery  process. 


Another  problem  that  many  civil  works  organizations  are  facing  is  the  loss  of 
many  veteran  personnel  as  a  result  of  budget  reduction.  These  personnel 
possess  a  vast  amount  of  knowledge  and  experience  in  the  civil  works 
organization. 

The  implementation  of  an  automated  system  that  can  captvme,  store,  and  share 
knowledge  and  experience  of  all  project  participants,  throughout  all  phases  of 
the  project  life  cycle,  will  help  reduce  the  problem  caused  by  a  fragmented 
delivery  process.  This  system  can  also  capture  the  experiential  knowledge  of 
veteran  personnel  before  they  leave  the  organization.  The  information  these 
people  possess  is  essential  to  the  civil  works  organization’s  future  existence. 

This  report  describes  the  development  and  implementation  of  such  a  system,  the 
Organizational  Knowledge  Bank  (OKBank).  The  OKBank  system  takes  the 
advantages  of  the  world  wide  web  (WWW)  and  other  relational  software 
programs  in  effectively  capturing,  processing,  and  disseminating  organizational 
knowledge.  The  knowledge  base  in  the  OKBank  contains  not  only  organizational 
experiences  such  as  lessons  learned,  good  work  practices,  and  success  stories,  but 
also  includes  project  information  that  is  geographically  oriented. 


Objective 

The  objective  of  this  research  was  to  investigate  how  organizationed  knowledge 
in  design,  construction,  and  operations  offices  may  be  captvued,  evaluated, 
stored,  retrieved,  and  applied  to  enhance  the  cost,  time,  quality,  and  operational 
value  of  future  work. 


Approach 

This  work  was  conducted  as  a  joint  project  between  the  Corps’  Wcksburg  District 
office,  the  Department  of  Civil  and  Environmental  Engineering  at  the  Georgia 
Institute  of  Technology,  the  Construction  Technology  Transfer  Center,  and  the 
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U.S.  Army  Construction  Engineering  Research  Laboratories  (USACERL).  The 
approach  used  to  complete  the  research  was  to  investigate  and  review  existing 
automated  lessons  learned  systems,  to  identify  deficiencies  within  those  existing 
systems,  to  develop  strategies  required  to  support  the  engineering  of  large  public 
works  structures,  and  to  demonstrate  the  approach  by  developing  a  prototype 
software  system. 


Mode  of  Technology  Transfer 

The  results  of  this  work  apply  to  all  levels  of  government  and  private  firms  that 
manage  public  works  structures  and  facilities.  In  addition,  the  results  may  also 
be  applied  to  the  private  sector  as  an  approach  to  consider  when  developing  tools 
for  the  capture  of  corporate  knowledge. 

The  results  of  this  work  are  available  at  http://www-2.cecer.army.mil/okbank/ 
index.html.  The  demonstration  system  is  under  evaluation  by  various  members 
of  the  Corps  of  Engineers  and  the  Construction  Technology  Transfer  Center. 
Following  this  informal  review,  plans  to  complete  and  distribute  or  serve  the 
completed  system  may  be  created. 
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2  Current  Industry  Efforts  and  Practices 

Approach 

Most  organizations  have  recognized  the  potential  benefit  of  lessons  learned 
systems  in  construction  projects.  However,  only  in  the  past  several  years,  as  the 
computer’s  technologies  became  more  and  more  powerful  and  accessible,  have 
automated  lessons  learned  systems  become  more  feasible. 

Literature  reviews  indicated  that  much  research  and  development  effort  has 
been  done  in  this  area.  A  thorough  search  of  various  sources  (libraries,  the 
Internet,  and  personal  contacts)  revealed  many  automated  lessons  learned 
systems. 

Each  of  the  available  automated  lessons  learned  systems  was  reviewed  to 
determine  the  current  state  of  the  art.  An  evaluation  guideline,  which  focuses  on 
project  life  cycle,  was  developed  to  provide  consistency  and  to  guide  the 
reviewing  process.  Questions  addressed  include: 

1.  Which  phase  or  phases  within  the  project  life  cycle  does  the  system  address? 

2.  Are  all  aspects  in  each  phase  covered? 

3.  How  does  the  system  define  “lessons  learned”? 

4.  How  are  the  lessons  and  data  captured? 

5.  How  and  what  information  is  stored? 

6.  How  are  the  lessons  disseminated? 

7.  Can  the  data  be  updated  and  maintained? 


8.  What  are  the  missing  pieces? 
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System  Reviews 

Overall,  the  reviews  indicated  that  many  systems  share  a  common  belief  that  the 
most  effective  form  of  constructability  is  the  integration  of  construction  lessons 
learned  in  the  design  process.  Most  developers  of  the  latest  systems  also  agreed 
that  the  best  mechanism  for  integration  of  lessons  learned  is  through  the 
Internet.  A  multimedia  system  (i.e.,  with  pictures,  graphics,  audio,  and  video 
clips)  was  also  strongly  recommended  for  enhancing  the  application  of  lessons 
learned.  Each  system  is  described,  analyzed,  and  evaluated  in  the  following  text. 

The  Constructability  Lessons  Learned  Database  System 

General  description.  The  Constructability  Lessons  Learned  Database  (CLLD) 
system  provides  an  interactive  computerized  method  of  collecting,  storing,  and 
making  constructability  knowledge  available  (Kartam  1995).  This  system  is 
designed  to  capture  only  lessons  that  are  generated  and  can  be  applied  during 
the  construction  phase.  The  system  description  and  lessons  learned  examples 
used  in  the  system  prototype  indicate  that  its  primary  emphasis  is  on 
construction  techniques  and  construction  methodologies. 

The  system  defines  lessons  learned  as  knowledge  generated  through  daily  con¬ 
struction  activities.  The  lessons  involve  both  positive  and  negative  experiences 
gained  during  the  construction  phase. 

System  design  and  implementation.  The  primary  source  of  construction  knowledge 
for  the  CLLD  system  was  from  personal  interviews  with  all  construction 
employees,  from  vice  presidents  and  project  managers  to  the  foremen  emd 
construction  laborers.  The  personal  interview  process  followed  a  three-step 
format.  The  pre-interview  planning  was  done  by  phone  to  give  the  interviewee  a 
brief  overview  of  the  reason  for  calling,  a  description  of  the  CLLD  capabilities,  a 
detailed  description  of  what  was  being  requested  from  the  employee,  and  a  time 
and  date  for  the  actual  interview.  The  actual  interview  was  conducted  using  the 
two-interviewer  approach.  Probing  questions  and  previous  examples  of  usable 
lessons  learned  were  used  during  the  interview.  The  post-interview  activities 
included  follow-up  contacts  with  the  employee  for  final  revision  Or  further 
contribution  of  lessons. 

In  addition  to  the  interview  method,  an  automated  mechemism  called  a 
“discussion  window”  has  been  added  to  the  CLLD  system  so  contributors  can 
input  their  lessons  directly  into  the  system. 


10 


USACERL  SR  98/64 


Each  of  the  submitted  lessons  is  reviewed  and  approved  by  a  company’s 
committee  before  it  can  be  added  to  the  permanent  database.  The  committee  is 
composed  of  construction  practitioners  with  ample  experience  in  the  trade. 

The  primary  classification  source  used  in  this  system  is  based  on  the  16  Division 
CSI  MASTERFORMAT  System  for  building  construction.  Users  can  access  the 
database  through  such  routes  as  category,  keyword,  lesson  title,  etc.  The 
database  contains  primarily  written  text.  The  lessons  learned  database  operates 
on  IBM-compatible  personal  computers  through  the  use  of  Lotus  Notes™ 
software  in  MS-Windows™. 

Evaluation.  One  highlight  of  this  system  is  the  systematic  interviewing  approach 
used  for  knowledge  acquisition.  The  personal  interviews  not  only  provided  a 
significant  source  of  information  for  the  database,  but  also  gave  the  employees 
the  opportunity  to  learn  about  and  be  part  of  the  system. .  This  knowledge,  in 
turn,  will  promote  and  ease  the  acceptance  of  the  system. 

Another  useful  concept  presented  in  this  system  was  to  include  both  positive  and 
negative  experiences  in  the  database.  Wording  the  failures  in  a  manner  that 
offers  positive  preventive  advice  rather  than  reporting  negative  results  is 
excellent;  Doing  this  will  encourage  users  to  contribute  their  personal 
experience. 

The  CLLD  system  only  addresses  lessons  learned  within  the  construction  phase 
of  the  project  life  cycle,  with  emphasis  on  construction  techniques  and 
methodologies.  It  is  not  clear  whether  the  system  will  also  cover  lessons  in  other 
aspects  of  the  construction  phase  such  as  cost,  schedule,  and  quality.  No 
systematic  method  exists  for  appljdng  the  lessons  to  future  work. 

The  system  developer  mentioned  that  pictures  and  graphics  can  be  incorporated 
into  the  CLLD  system  with  Lotus  Notes’  capabilities  to  import  files  from  other 
softweire  programs.  However,  no  particular  software  was  mentioned. 

The  Intelligent  Information  Retrieval  and  Expert  Advice  for  the 
Construction  of  Highway  System 

General  description.  The  Intelligent  iNformation  Retrieval  and  Expert  Advice  for 
the  Construction  of  Highway  (IN  REACH)  system  assists  both  veteran  and 
novice  practitioners  in  fashioning  more  informed  decisions  concerning  problems 
that  may  arise  during  normal  and  abnormal  highway  construction  operations 
(Epstein  1995).  This  system  primarily  focuses  on  “inspection  operations”  in  the 
construction  phase. 
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This  system  defines  lessons  learned  as  any  information  that  can  assist 
construction  personnel  to  better  perform  their  jobs.  Developed  under  this 
concept,  the  knowledge  base  in  the  IN  REACH  system  is  not  limited  to 
construction  knowledge  and  expertise  of  veteran  personnel,  but  also  includes 
existing  data  and  documentation.  Examples  of  existing  documents  include: 
standard  specifications,  standard  drawings,  construction  administration 
manuals,  and  inspection  manuals. 

System  design  and  implementation.  The  initial  data  in  the  IN  REACH  system  are 
captured  directly  from  selected  sections  of  manuals  and  documents  already 
existing  in  the  organization.  This  existing  information  makes  up  the  majority  of 
the  data  for  the  IN  REACH  system.  The  initial  data  are  supplemented  by 
knowledge  and  expertise  of  veteran  personnel  derived  from  mandatory  post¬ 
construction  conferences. 

Although  IN  REACH  uses  an  expert  system  approach,  it  does  not  represent  the 
captured  information  in  terms  of  rules.  Rather  “...the  dociunents  themselves, 
along  with  the  comments  collected  from  the  post  construction  conferences,  were 
utilized  to  represent  the  captured  knowledge  of  the  orgeinization”  (Epstein  1995). 
The  data  are  stored  under  six  general  categories:  bridge,  roadway,  asphalt, 
signaling  and  lighting,  maintenance  of  traffic,  and  other.  Each  general  category 
is  further  broken  down  into  source  indexes.  Each  source  index  contains 
information  for  a  specific  operation  such  as  pile  driving.  Most  of  the  data  are 
written  text. 

The  system  is  operated  in  a  Windows  environment  and  is  menu  driven.  Users 
can  retrieve  information  either  by  selecting  a  topic  on  the  menu  or  by  searching 
for  a  topic.  The  program  is  ^mtten  in  KnowledgePro  Windows™,  a  combination 
of  objected-oriented  programming  (OOP),  expert  systems,  and  hypertext. 

Evaiuation.  The  use  of  both  veteran  expertise  eind  existing  documentation  to 
represent  the  system’s  knowledge  base  is  an  interesting  concept.  Because  the 
main  objective  of  all  lessons-leamed  systems  is  to  improve  performance,  these 
systems  would  be  more  complete  if  they  also  contained  information  (other  than 
lessons  learned)  that  can  assist  personnel  in  doing  their  jobs  better. 

The  post-construction  conference  is  a  good  way  to  capture  lessons  learned  while 
they  are  still  fresh  in  the  minds  of  the  involved  parties.  Most  organizations  have 
mjmerous  meetings  and  conferences  before  and  during  the  task,  but  not  after  the 
task  is  finished.  The  lessons  derived  from  these  conferences  could  be  used  to 
update  or  supplement  the  existing  data.  In  this  way,  the  system  becomes  a 
“living”  electronic  document  that  becomes  more  and  more  useful. 


12 


USACERL  SR  98/64 


The  IN  REACH  program  contains  primarily  text  with  sketches  or  drawings.  No 
mechanism  exists  for  users  to  input  new  lessons.  How  the  data  will  be 
maintained  and  updated  was  not  discussed. 

Constructability  Support  Multimedia  System 

General  Description.  The  Indiana  Department  of  Transportation  (INDOT) 
Constructability  Support  Multimedia  System  is  a  computer  tool  that  captures, 
records,  and  stores  constructability  concepts  and  lessons  learned  while  providing 
design  professionals  with  easy  access  and  graphical  retrieval  of  concepts  and 
lessons  to  deepen  their  understanding  of  constructability  issues  (Patty  1995). 
The  system  was  developed  for  use  by  designers. 

This  system  stores  constructability  information  and  lessons  learned  during 
construction.  The  author  defines  constructability  as  the  integration  of  construc¬ 
tion  knowledge  and  experience  during  all  phases  of  the  facility  development 
process.  The  construction  ‘lessons  learned”  is  not  clearly  defined. 

A  special  feature  of  this  system  is  its  use  of  multimedia  to  represent  a  broad  field 
of  knowledge.  The  developer  argued  that  text  alone  was  rather  unnatural  and 
difficult  to  see  when  explaining  a  wide  range  of  construction  knowledge.  This 
system  used  text,  full  color  images,  and  video  clips  to  represent  and  explain 
constructability. 

System  design  and  implementation.  The  knowledge  acquisition  process  begins 
with  videotaping  interview  sessions  with  construction  contractors,  INDOT 
personnel,  and  the  design  consultant.  The  interview  sessions  are  reviewed  to 
identify  lessons  learned  candidates.  Then  information  and  data  related  to  each 
lesson  are  collected  to  fully  explain  the  lessons. 

The  system  has  four  windows  and  each  window  represents  a  level.  The  Main 
Level  represented  four  main  construction  categories:  Bridges,  Roads, 
Environmental,  and  Contracts.  The  second  window  was  the  Organization  Level, 
which  contained  design  category  icons  of  the  Main  Level  choice.  The  third 
window  was  the  Detail  Level,  which  contained  icons  of  actual  constructability 
lessons  learned.  The  fourth  level  contained  a  graphic  representing  the  lessons 
learned.  At  this  level,  users  could  activate  a  search  process  for  the  lessons 
learned.  The  lessons  learned  are  described  in  a  textual  format  that  also  contains 
hyperlinks  to  other  multimedia  such  as  pictures,  graphics,  audio,  and  video  clips. 
Users  maneuver  throughout  the  system  simply  by  clicking  on  an  icon  in  any 
window. 
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The  system  is  composed  of  a  custom  access  interface  written  in  Microsoft  Visual 
Basic™  and  FolioViews™  electronic  publishing  software.  As  of  Jvily  1997,  INDOT 
was  in  the  process  of  producing  this  system  in  a  CD-ROM  format. 

Evaluation.  This  system  provides  an  excellent  answer  to  the  retrieval  phase  by 
describing  a  multimedia  system  that  contains  meaningful  lessons  learned.  Many 
lessons  learned  in  construction  may  not  be  adequately  described  with  written 
text.  The  multimedia  capability  will  enhance  the  lessons  tremendously. 

The  establishment  of  each  lesson  will  require  significant  time  and  effort.  When 
put  on  a  CD-ROM,  the  data  are  permanent  and  cannot  be  updated,  unless  a  new 
CD  is  burned.  The  CD-ROM  format  will  limit  the  dissemination  of  lessons 
learned  to  only  a  small  number  of  users.  No  systematic  approach  is  available  for 
applying  the  data  to  future  projects. 

DOE  Complex-wide  Lessons  Learned  Program 

General  description.  The  Department  of  Energy  (DOE)  Complex-wide  Lessons 
Learned  Program  is  designed  to  promote  consistency  and  compatibility  among 
existing  lessons  learned  programs  across  the  DOE  complex. 

In  the  existing  programs,  lessons  learned  are  defined  as  the  utilization  and 
sharing  of  information  relative  to  improving  the  health  and  safety  at  DOE’s 
facilities,  and  to  make  recommendations  for  improvement.  In  the  new  program, 
the  concept  of  lessons  learned  is  broadened  to  include  all  areas  of  DOE  business. 
The  lesson  learned  is  also  redefined  as  a  “good  work  practice”  or  innovative 
approach  that  is  captured  and  shared  to  promote  repeat  application.  It  may  also 
be  an  adverse  work  practice  or  experience  that  is  captvued  and  shared  to  avoid 
recmrence. 

System  design  and  Implementation.  Information  used  to  generate  lessons  learned 
may  come  from  numerous  sources  such  as  personal  experiences,  occmrence 
reports,  safety  meetings,  quality  coxmcil  meetings,  nonconformance  reports, 
safety  bulletins,  project  planning  and  evaluation  results,  performance 
improvement  initiatives,  and  process  improvement  initiatives.  The  sources  are 
not  limited  to  DOE  but  include  other  Federal  agencies  and  the  industry  as  well. 

Information  that  has  potential  to  become  a  lesson  leeumed  is  required  to  undergo 
two  review  processes  before  dissemination.  The  technical  review  is  performed  by 
subject  matter  experts  or  the  Lessons  Learned  Coordinator  to  determine  the 
applicability  and  significance  of  a  potential  lesson  learned  and  whether  the 
experience  has  been  included  in  a  previously  issued  lessons  learned  dociunent. 
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The  lesson  learned  is  then  reviewed  for  compliance  with  organizational  security 
requirements  before  being  stored. 

The  DOE  lessons  learned  program  uses  electronic  and  non-electronic  approaches 
in  lessons  dissemination.  Lessons  learned  are  electronically  disseminated  by  the 
DOE  Lessons  Learned  Information  System  (LLIS).  This  system  uses  the 
Internet  to  make  information  developed  at  local  levels  available  to  other  sites 
across  the  DOE  complex.  Lessons  learned  posted  in  this  system  follow  a 
specified  template.  Non-electronic  dissemination  methods  include  meetings, 
teleconferences,  workshops,  publications,  and  direct  mailings. 

Some  of  the  electronic  means  used  in  this  system  are:  List  Server,  Newsgroups, 
Electronic  Mail,  and  Internet  Web  Site.  The  List  Server  is  limited  to  the  DOE 
community.  The  Internet  Web  Page,  as  part  of  a  pilot  program,  is  used  as  a 
means  to  quickly  share  information  among  the  field  offices. 

Evaluation.  One  highlight  of  the  DOE  program  is  the  support  by  upper 
management.  Programs  such  as  the  DOE  Complex-wide  lessons-learned  system 
impact  and  require  the  cooperation  of  many  employees,  not  to  mention  the  need 
for  other  resources.  Without  the  support  from  the  top  echelon,  this  program  will 
not  survive  even  the  developmental  phase. 

This  system  also  encourages  the  submission  of  “good  practices,”  which  is  missing 
in  many  other  lessons  learned  systems.  This  concept  fits  well  into  the  main 
objective  of  all  lessons  learned:  that  is,  to  improve  performance  of  the  project. 

The  use  of  the  Internet  to  vddely  disseminate  the  lessons  learned  is  excellent.  In 
this  way,  the  whole  industry  can  benefit  from  the  system. 

The  program  covers  all  areas  of  DOE  business,  including  construction.  In  the 
construction  area,  however,  the  program  only  focuses  on  safety  aspects  of  the 
construction  phase  and  the  operation  phase  of  the  project  life  cycle.  The  lessons 
are  primarily  safety  related  and  operational  in  nature.  Most  lessons  learned  are 
presented  primarily  in  vmtten  text. 

The  program  requires  that  stored  lessons  learned  information  be  reviewed  for 
usefulness.  Information  that  is  no  longer  pertinent  to  organizational  activities  is 
to  be  eliminated  or  archived  in  accordance  with  organizational  policies  and 
procedures.  It  is  not  clear  how  and  iinder  what  format  the  lessons  are  stored. 

The  DOE  lessons  learned  program  also  includes  a  requirement  for  applicable 
lessons-learned  information  to  be  incorporated  into  DOE  and  contractor 
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activities.  However,  no  mechanism  ensures  that  the  information  will  actually  be 
used. 

Unking  Lessons  Learned  System 

General  description.  The  Linking  Lessons  Learned  (L3)  system  is  an  effective 
means  for  communicating  experiences  of  construction  and  operation  teams  to 
benefit  the  designer  on  subsequent  projects  (Phillips  1996).  The  L3  system  is 
designed  to  be  used  by  designers  during  the  design  process. 

It  is  not  clear  how  lessons  learned  are  defined  in  this  system.  However,  from  the 
system  description  and  examples  of  the  lessons  in  the  database,  it  seems  that  the 
lessons  are  derived  from  design  deficiencies  discovered  during  construction  and 
operation  phases. 

System  design  and  implementation.  The  main  source  for  the  lessons  learned  comes 
from  employee  experience.  A  lessons  subrhittal  form  (both  electronic  and  hard 
copy)  is  required  to  facilitate  the  submission  process.  Other  sources  of  lessons 
include  knowledge  and  experience  of  customers,  contract  changes,  contract 
claims,  value  engineering  change  proposal  (VECP),  biddability,  constructability, 
and  operability  (BCO)  review  comments,  and  post-construction  conferences. 

An  oversight  committee  then  reviews  each  submitted  lesson.  This  committee  is 
also  responsible  for  keeping  data  current,  publicizing  the  system  and  inspiring' 
enthusiasm  for  it  in  the  organization,  and  ensuring  the  software  is  up-to-date 
and  progressive. 

Once  a  lesson  is  reviewed  and  approved,  the  system  administrator  will  enter  it 
into  the  database  called  the  L3  Application  System.  This  database  system  was 
developed  using  Microsoft  Access  2.0™  relational  database  software.  The 
developer  also  uses  the  Internet  as  a  supplemental  method  for  making  lessons 
available.  The  L3  Application  system  can  be  downloaded  from  the  Internet. 

The  lessons  are  organized  under  the  combination  of  phases  (planning,  design, 
construction,  and  operation)  and  disciplines  (architectural,  ci'vil,  electrical, 
environmental,  mechanical,  sitework,  and  structural).  Users  can  access  the 
lessons  either  from  the  Internet  or  from  the  L3  Application  system.  All  lessons 
learned  in  the  database  contain  only  •written  text. 

The  system  developer  proposes  that  designers  of  all  projects  he  required  to 
certify  that  they  have  reviewed  all  applicable  lessons  leEumed  in  the  system  as 
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part  of  the  design  process.  Training  and  partnering  efforts  are  recommended  to 
overcome  the  resistance  from  the  designers  to  such  a  requirement. 

Evaluation.  One  highlight  of  this  system  is  a  clear  mechanism  to  ensure  the 
utilization  of  the  system  by  designers.  The  lesson  is  not  “learned”  imtil  it  is  used 
to  avoid  the  same  mistakes  or  to  improve  performance. 

As  in  the  DOE  LLIS,  this  system  also  uses  the  Internet  to  widely  disseminate 
the  lessons  learned.  Again,  by  making  the  lessons  globally  available,  many  other 
construction  organizations  can  also  learn. 

The  system  has  some  options  for  application  in  other  phases  of  the  project  life 
cycle.  However,  it  is  evident  from  the  system  design  concepts  that  the  main 
focus  is  on  the  design  review  process. 

The  system  does  not  have  the  capability  to  capture  the  lessons  automatically  as 
it  is  designed  for  a  “...data  storage  and  retrieval  piupose”  (Phillips  1996). 

Design  Review  and  Checking  System 

General  description.  The  Design  Review  and  Checking  System  (DrChecks)  uses  a 
client/server  approach  across  the  Internet  to  capture  successes  and  failimes  of 
experienced  design  and  construction  personnel  for  use  within  the  design  review 
process  (East  1996).  The  program  demonstrates  in  detail  a  complete  cycle 
process  of  capturing,  reviewing,  storing,  and  retrieval  of  lessons  learned  via  the 
WWW. 

This  system  defines  lesson  learned  as  “...knowledge  or  understanding  gained  by 
experience.  The  experience  may  be  positive,  as  in  a  successful  test  or  mission,  or 
negative,  as  in  a  mishap  or  failme.  Successes  are  also  considered  sources  of 
lessons  learned.  A  lesson  must  be  significant  in  that  it  has  a  real  or  assurned 
impact  on  operations;  valid  in  that  it  is  factuedly  and  technically  correct;  and 
applicable  in  that  it  identifies  a  specific  design,  process,  or  decision  that  reduces 
or  eliminates  the  potential  for  failures  and  mishaps,  or  reinforces  a  positive 
result”  (East  1996). 

DrChecks  also  defines  a  lesson  learned  as  a  good  work  practice  or  innovative 
approach  that  is  captured  and  shared  to  promote  application.  It  may  also  be  an 
adverse  work  practice  or  experience  that  is  captimed  and  shared  to  avoid 
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The  developer  specifically  proposes  that  the  lessons  captured  must  have  a  real 
impact  on  operations,  be  factually  or  technically  correct,  have  application  to  a 
specific  process  or  component  and  have  limited  management  implication.  Once 
captured  items  become  lessons  learned,  they  must  be  shared  with  personnel  at 
the  time  when  the  lessons  can  be  applied  at  the  least  cost  (typically  during 
design)  to  improve  the  success  of  each  new  project.  The  system  is  developed 
based  on  the  corporate  learning  process  where  project-based  learning  is 
extracted  from  the  personnel  directly  involved  in  the  project  cycle  to  be  shared 
throughout  the  organization. 

System  design  and  implementation.  The  “author”  submits  the  potential  lesson 
learned  directly  into  the  system.  Three  types  of  information  are  required:  (1) 
the  project  on  which  the  lesson  has  occurred,  (2)  a  description  of  the  problem, 
and  (3)  a  recommended  solution. 

The  submitted  lesson  is  then  reviewed.  The  reviewer,  either  personally  or  by 
routing  the  item  to  appropriate  personnel,  determines  if  a  submitted  item  has  a 
real  impact  on  operations,  is  factually  and  technically  correct,  has  application  to 
a  specific  process  or  component,  and  has  limited  management  implication.  Once 
the  reviewer  (or  technical  specialist)  has  evaluated  the  potential  lesson,  the 
lesson  is  made  available  to  the  user  group  for  access. 

All  of  the  above  steps  are  facilitated  by  DrChecks.  The  major  components  of  this 
system  and  the  general  flow  of  information  are  illustrated  below. 

The  user  uses  the  system  by  accessing  standard  WWW  pages  containing 
Hypertext  Markup  Language  (HTML)  tags.  The  user  begins  a  query  through  a 
form  action  contained  in  the  HTML  page.  The  web  server  receives  the  query  and 
executes  another  web  page  called  the  template  file,  which  contains  both  HTML 
and  scripts  formatting  tags.  Based  on  the  scripting  information  contained  in  the 
template  file,  a  query  is  posted  to  the  scripting  processing  program.  The 
scripting  tags  and  the  script  processing  program  are  provided  by  Allire 
Corporation’s  Cold  Fusion  product.  The  script  processing  program  uses  a  set  of 
HTML  extensions  called  Data  Base  Markup  Language  (DBML). 

Then  the  query  is  posted  to  the  data  som*ce,  Microsoft  Access  database  (version 
2.0),  and  the  result  of  the  query  or  other  actions  are  taken.  Based  on  the 
formatting  information  provided  in  the  template  file,  query  results  are  returned, 
and  an  HTML  document  is  produced.  The  result  page  is  provided  to  the  user 
through  the  web  server. 
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Evaluation.  This  system  is  one  of  the  most  recently  developed  lessons  learned 
system.  It  took  the  advantages  of  the  WWW  and  other  relational  software 
program  in  effectively  capturing,  processing,  and  disseminating  lessons  learned. 
This  approach  is  realistic  and  useful  for  integrating  the  capture  and  use  of 
lessons  learned. 

Like  many  other  lessons  learned  system,  DrChecks  focuses  on  the  design  review 
process.  The  system  limits  itself  to  include  only  lessons  that  are  technically 
oriented.  It  is  mainly  textual  and  does  not  include  other  multimedia  data. 


Overall  Summarization  of  System  Reviews 

The  review  indicates  that  most  systems  were  developed  for  use  during  the  design 
process.  Two  of  them,  however,  are  designed  and  used  mainly  for  the 
construction  phase.  Many  of  these  systems  focus  on  one  or  two  aspects  in  each 
phase  of  the  project  life  cycle,  such  as  design  deficiencies,  safety,  construction 
methods  and  techniques,  inspection,  etc.  No  system  covers  the  entire  project  life 
cycle. 

All  systems  basically  agreed  that  the  definition  of  lessons  learned  is  both  positive 
and  negative  experiences  captured  and  shared  to  improve  performance. 
However,  there  was  a  big  difference  in  what  information  needed  to  be  captvired. 
Four  of  these  six  systems  limited  their  database  to  include  only  lessons  learned. 
These  lessons  were  primarily  technically  related.  The  database  of  the  other  two 
systems  included  a  wide  range  of  information,  and  lessons  learned  data  were  just 
part  of  a  much  larger  database.  Except  data  in  the  INDOT  system,  which 
includes  multimedia  information,  data  in  other  systems  were  primarily  written 
text. 

Most  of  the  systems  capture  lessons  manually.  Some  systems  are  supplemented 
by  electronic  meeins.  DrChecks  is  the  only  system  that  is  fully  automated  to 
capture  potential  lessons  via  a  WWW  site.  Except  the  DOE  LLIS,  which  uses 
both  electronic  and  non-electronic  methods  to  promote  the  widest  distribution  of 
lessons  learned,  the  rest  of  the  systems  were  designed  for  automated  retrieval. 

,  Three  of  the  six  systems  can  be  accessed  through  the  Internet. 

All  systems  have  a  mechanism  for  reviewing  and  approving  lessons  learned 
before  placing  them  into  the  permanent  database.  This  review  function  is 
usually  done  by  an  assigned  individual  or  by  an  appointed  oversight  committee. 
Except  for  INDOT’s  permanent  database,  information  from  other  systems  can  be 
updated  as  needed.  Table  1  svunmarizes  the  system  reviews. 
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Table  1.  Highlights  of  lessons-learned  system  reviews. 


Primary 

Focus 

Data 

Captured 

Type  of 
Data 

Multi¬ 

media 

Fullest 

Dissemination 

Capability 

Operating 

System 

CLLD 

Construction 

Semi-auto 

No 

In  house 

Windows 

IN  REACH 

Construction 

Manual 

Includes 
other  data 

No 

in  house 

Windows 

INDOT 

Yes 

In  house 

Windows 

DOE  LLtS 

Operation 

Manual 

Includes 

otherdata 

No 

Global 

Windows 

L3 

Manual 

losoymi 

No 

Global 

Windows 

DrChecks 

I^SSSESliiH 

Automated 

LL  only 

No 

Global 

Windows 

other  Recent  Developments 

In  addition  to  the  above  systems,  other  research  has  been  done  on  this  topic 
recently.  One  of  the  major  research  efforts  is  a  2-year  study  by  the  University  of 
New  Mexico  under  the  sponsorship  of  the  Construction  Industry  Institute  (CII). 
The  study  emphasis  on  “process”  rather  than  “database”  allows  flexibility  for 
companies  to  adapt  the  model  to  their  own  in-house  capabilities.  The  result  of 
this  study  is  a  “flow  process  model  that  should  gviide  the  industry  on  the 
mechanics  of  utilizing  LL,  how  they  can  be  captured,  how  to  filter  information 
and  how  to  organize  it  for  retrieval”  (Fisher  1997). 

A  special  product  in  the  form  of  a  WWW-based  lessons  learned  server  has  also 
been  created,  but  is  not  yet  available.  Based  on  the  description  of  this  product  in 
Fisher  (1997),  it  is  very  similar  to  that  of  DrChecks  discussed  in  detail  eau'lier  in 
this  chapter. 

The  CII’s  study  also  summarizes  the  attributes  of  an  ideal  software  tool  for  a 
lessons  learned  system.  This  excellent  tool  will  be  discussed  in  Chapter  3. 

Another  system  currently  xmder  development  is  the  Constructability,  Operability, 
and  Maintainability  Lessons  Learned  (COML2)  system  (Vanegas  1997).  Again, 
this  system  proposes  using  the  WWW  site  as  a  means  to  receive,  store,  and  allow 
retrieval  of  lessons  learned  similar  to  that  of  DrChecks. 

The  COML2  system  is  based  on  the  global  concept  of  integrating  lessons  learned, 
which  includes  constructability,  operability,  and  maintainability  with  edl  phases 
of  the  facility  development  processes,  across  multiple  organizations  and 
disciplines.  This  global  concept  has  been  missing  from  most  lessons  learned 
systems  now  implemented.  The  idea  of  integrating  lessons  learned  to  include  all 
phases,  across  multiple  organizations  and  disciplines,  will  be  discussed  further 
in  Chapter  3. 
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3  System  Development 


As  mentioned  in  Chapter  2,  the  idea  of  integrating  lessons  learned  to  include  all 
phases  of  the  project  life  cycle,  across  multiple  organizations  and  disciplines,  is 
very  interesting.  This  global  concept  is  missing  from  most  lessons  learned 
systems  currently  implemented.  This  chapter  explores  this  concept  to  determine 
its  applicability  to  the  design  of  a  system  for  use  in  the  Corps  of  Engineers 
Vicksburg  District. 

The  evaluation  of  current  systems  indicated  that  major  differences  exist  in  the 
types  of  information  that  make  up  the  system  knowledge  base.  Some  systems 
only  include  lessons  learned,  while  some  contain  other  organizational 
information.  The  type  of  information  that  will  make  up  the  knowledge  base  for 
the  proposed  system,  and  how  it  will  be  acquired,  will  also  be  determined  and 
described  in  this  chapter. 

Along  with  knowledge  acquisition,  one  critical  aspect  of  the  knowledge  and 
experience  capture  program  is  the  proposed  method  of  disseminating  the 
captured  information.  The  captured  information  must  be  validated,  organized, 
stored,  and  presented  in  such  a  way  that  it  is  readily  available  and  easily 
accessible  to  anyone  wishing  to  benefit  from  the  knowledge  base*.  All  of  these 
processes  will  be  described  in  this  chapter. 

Finally,  computer  technology  will  be  examined  to  determine  what  software  is 
most  complementary  and  suitable  to  the  processes. 

Project  Life-Cycle  Concept 

It  is  universally  agreed  that  the  most  effective  way  to  improve  future  project 
performance  is  the  integration  of  construction  lessons  learned  into  the  design 
process.  However,  some  system  developers  recognize  that  performance  during 
the  construction  phase  could  also  be  improved  through  a  similar  formalized 
feedback  system.  The  CLLD  and  IN  REACH  systems  are  developed  to  do  just 
that.  It  is  just  a  matter  of  time  until  other  phases  within  the  project  life  cycle 
such  as  planning,  contracting,  and  operations  and  maintenance  (O&M)  will  be 
included  in  the  effort. 
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In  civil  works,  each  phase  within  the  project  life  cycle  has  a  unique  focus, 
multiple  stakeholders,  and  a  wide  range  of  specific  tasks  that  need  to  be 
accomplished.  For  example,  the  planning  process  for  a  water  resource  problem 
starts  with  a  brief  study  to  determine  whether  the  project  falls  within  the  Corps’ 
statutory  authority  and  meets  national  priority.  Should  that  be  the  case,  the 
Corps  will  carry  out  a  full  feasibility  study  to  develop  alternatives  and  select  the 
best  possible  solution.  This  process  normally  includes  public  meetings  to 
determine  the  views  of  local  interests.  The  planning  phase  might  also  involve 
other  Federal  and  state  agencies  with  interests  in  the  project. 

Unquestionably,  lessons  vrill  be  learned  in  this  lengthy  review  and  approval 
process.  Certain  knowledge  and  experience  gained  fi'om  the  planning  stages 
(e.g.,  how  to  conduct  a  productive  public  meeting,  why  a  certain  project  is 
stopped,  things  that  can  be  done  to  expedite  the  approval  process)  might  be 
valuable  to  future  projects. 

Likewise,  knowledge  and  experience  gained  during  the  O&M  of  a  project,  even  if 
they  could  be  applied  only  within  the  O&M  process,  would  result  in  tremendous 
cost  savings.  The  O&M  cost  of  a  levee  system,  for  example,  is  far  greater  than 
its  design  cost  or  initial  construction  cost.  Knowledge  and  experience  gained  by 
one  Levee  District,  such  as  what  piece  of  equipment  works  best  for  mowing  the 
levee,  wiU  benefit  other  Levee  Districts.  Knowledge  and  experience  gained  from 
fighting  a  recent  flood  would  also  benefit  future  operations. 

The  above  examples  suggest  that  many  incentives  exist  for  the  effective 
apphcation  of  knowledge  and  experience  gained  at  all  phases  throughout  the 
project  hfe  cycle,  across  multiple  organizations  and  disciplines,  from  one  project 
to  another.  Figure  2  shows  the  potential  role  and  value  of  knowledge  and 
experience  when  applied  within  a  project’s  life  cycle  and  to  fiiture  projects  at 
\^cksburg  District. 

Figure  2  represents  the  concept  of  a  global  system  that  can  capture  knowledge 
and  experience  gained  throughout  all  phases  of  a  project’s  life  cycle  to  be  used  to 
improve  performance  of  both  current  and  future  projects.  This  global  concept 
serves  as  the  basis  for  the  design  of  the  system  prototype. 
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Figure  2.  Knowledge  and  experience  transfer  within  and  between  projects. 


Type  of  Knowledge  and  Experience  Captured 

The  overedl  goal  of  this  research  project  was  to  develop  a  systematic  approach  for 
capturing  knowledge  and  experience  of  veteran  Corps  personnel,  to  organize  this 
information,  and  to  disseminate  it  to  the  widest  audience  possible.  As  an 
example  of  the  civil  works  projects  referred  to  in  Chapter  1,  \^cksbiu*g  District  is 
responsible  for  a  variety  of  projects  in  Arkansas,  Louisiana,  and  Mississippi. 
These  projects  include  levees,  channel  improvement,  emergency  bank  protection, 
waterways,  and  erosion  control.  The  Red  River  below  Denision  Dam  Levees 
system  (in  Arkansas  and  Louisiana)  was  selected  as  the  area  of  focus  for  the 
design  of  a  system  prototype.  The  main  reason  the  levees  system  was  selected 
was  because  of  several  recent  flooding  events  in  the  United  States. 

Although  many  lessons  learned  system  developers  have  defined  lessons  learned 
as  both  positive  or  negative  experiences  that  are  captured  and  shared  to  improve 
performance,  the  term  “lessons  learned”  itself  inherently  projects  a  negative 
image.  Because  this  system  was  designed  to  capture  experiences  of  an 
organization,  the  term  “organizational  experiences”  seemed  more  appropriate. 
In  the  proposed  system,  organizational  experiences  (OEs)  are  defined  as  good 
work  practices,  success  stories,  or  innovative  approaches  in  an  organization  that 
are  captured  and  shared  to  promote  application.  They  may  also  be  adverse  work 
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practices  or  negative  experiences  that  are  captured  and  shared  to  avoid 
recurrence.  It  is  under  this  definition  that  the  knowledge  acquisition  process 
was  focused.  To  gather  the  initial  knowledge  base  for  the  system  prototype,  a 
personal  interview  approach  similar  to  that  of  the  CLLD  system  (Kartam  and  Al- 
Tabtabai  1995)  was  used. 

The  interview  process  included  three  steps.  First,  the  responsible  parties  from 
aU  phases  of  the  Red  River  Levees  project  were  contacted.  This  list  included  the 
divisions  for  Planning,  Program  and  Project  Management,  Real  Estate, 
Engineering,  Construction,  and  O&M.  The  initial  contacts  were  made  by 
telephone  to  give  the  interviewee  a  brief  overview  of  the  reason  for  the  call,  a 
detailed  description  of  what  was  requested  fi'om  the  employee,  and  a  time  and 
date  for  the  actual  interview.  The  initial  contacts  revealed  that,  besides  the 
common  stakeholders  of  traditional  projects,  most  civil  works  projects  such  as 
Red  River  Levees  also  involve  local  authorities  such  as  the  Levee  District 
Boards,  landowners,  and  private  citizens.  Since  the  local  Levee  Boards  are 
responsible  for  O&M  of  the  levee,  they  also  were  contacted  for  interviews. 

The  initial  contacts  also  indicated  that,  besides  OEs,  specific  project  information 
associated  with  a  certain  region  should  be  included  in  the  proposed  system  to 
assist  the  employees  in  performing  their  day-to-day  duties.  This  type  of 
information  is  usually  available  but  is  scattered  throughout  all  Divisions  within 
the  District.  Most  often  the  information  is  possessed  by  certain  employees  or 
individuals  who  have  lived  or  worked  in  that  region  for  a  long  time.  If  this 
information  is  not  captured,  it  will  be  gone  when  these  parties  are  no  longer 
available  for  consultation.  Even  if  it  is  captured  in  official  reports  and 
documents,  but  is  not  readily  available  and  easily  accessible,  its  benefits  will 
never  be  fully  recognized. 

In  the  case  of  the  system  prototype,  information  such  as  the  levee’s  history  might 
seem  trivial  to  many  employees,  but  it  is  very  important  to  the  archeologists, 
planners,  and  designers.  Furthermore,  factual  data  such  as  the  final  quantities 
and  final  itemized  payment  of  a  project  in  a  certain  region  generated  by  the 
Construction  Division  can  be  very  helpful  to  the  Planning  Division  in  the 
preliminary  estimates  for  a  similar  contract  within  the  same  geographical  area. 

Other  project  information  about  boundaries  and  points  of  contact,  for  each  Levee 
District  and  specific  permitting  requirements  associated  with  each  Levee  District 
is,  very  important.  This  type  of  specific  information  will  not  only  benefit  the 
organization  and  the  Levee  Districts  in  their  daily  operation,  but  also  can  help 
the  general  public  in  applying  for  a  permit  or  coping  during  flooding  events.  The 
idea  of  centrally  locating  this  t3q)e  of  information  is  very  attractive  to  the 
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customers.  The  Levee  Boards  and  landowners  will  no  longer  have  to  search 
several  places,  or  call  several  people,  for  specific  information  related  to  a  project 
in  their  jurisdiction  or  on  their  properties. 

It  is  interesting  to  note  that  other  systems  such  as  IN  REACH  and  DOE  LLIS  do 
not  limit  their  knowledge  base  to  just  project  lessons  learned.  This  broader 
knowledge  base  approach  is  also  supported  by  the  CII  study,  which  recommended 
that  “lessons  learned  should  not  be  limited  to  project  lessons  learned  only,  they 
can  also  come  from  personnel,  legal,  insurance,  or  any  other  department  which 
does  not  directly  participate  in  projects”  (Fisher  1997). 

Because  the  main  objective  of  all  lessons  learned  systems  is  to  improve 
performance,  and  the  initial  contacts  indicated  a  need  for  other  information  that 
can  assist  personnel  in  performing  their  day-to-day  jobs,  it  was  determined  that 
the  system  prototype  would  include  not  only  OEs,  but  also  other  projected- 
related  information. 

The  focus  of  the  knowledge  acquisition  process  was  then  expanded  to  include 
other  applicable  information.  The  intention  was  to  supplement  and  not  to 
replace  the  information  system  already  in  place,  so  the  project  information 
captured  for  use  in  this  system  was  the  knowledge  and  experience  that  were 
either  not  documented  or  documented  but  not  properly  shared.  Tb  determine 
what  project  information  to  include  in  the  system  prototype,  the  scope  of  the 
interview  was  also  changed  to  include  questions  such  as  what  project-related 
information/data  the  users  wanted  to  see  in  the  system  that  might  benefit  their 
day-to-day  operation.  Appendix  A  shows  a  questionnaire  created  to  assist  in  the 
interview  process. 

As  the  second  step  in  the  interview  process,  the  actual  interviews  were 
conducted  in  person.  Table  2  summarizes  the  results  of  the  interviews,  including 
information  that  the  users  would  like  to  see  in  the  prototype  system. 

The  table  indicates  that,  besides  OEs,  project-related  information  can  be  useful 
to  the  employees  and  the  customers.  Incorporating  the  suggested  information 
into  the  knowledge  base  of  the  system  will  make  the  system  more  attractive, 
which  in  turn  might  increase  the  contribution  of  experiences. 

The  personal  interviews  also  revealed  that  major  interest  exists  in  information 
on  projects  that  have  a  somewhat  indefinite  life  cycle,  such  as  levees,  flood 
control  structures,  and  navigation. 
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Table  2.  Summary  results  of  the  personal  interviews. 


Office/Division 

Contacted 

No.  Persons 
Interviewed 

No.  OE  Items 
Collected 

Other  Information  Suggested  To  Be 
Included  in  the  System  Prototype 

Planning 

1 

0 

Historical  cost  data  for  certain 
region  (geographical  area) 

Programming  & 

Project  Management 

1 

3 

Brief  project  overview,  Authorizing 
legislation,  &  local  cooperation 
reguirements 

Real  Estate 

1 

0 

Engineering 

1 

1 

As-built  drawings,  typical 
cross  sections 

Contracting 

1 

0 

Description  of  upcoming 
works,  anticipated  award  dates 

Construction 

3 

6 

Progress  update  of  the  overall 
proiect/program,  upcoming  works 

O&M 

1 

10 

Flood  reports,  flood  fighting  methods, 
boundaries,  points  of  contact  for  each 
levee  district 

Levee  Boards 

4 

5 

Points  of  contact  for  permit 
requirements.  Other  applicable 

Federal  standards/regulatlons 

The  final  step  of  the  interview  process  included  follow-up  contacts  with  the 
employees  for  final  revision  and/or  contribution  of  additional  experiences. 

The  majority  of  the  above  information  was  obtained  from  the  interviews  and 
throughout  the  development  process  of  the  prototype  system.  The  collected 
information,  along  with  OEs,  makes  up  the  knowledge  base-  for  the  system 
prototype. 

It  is  important  to  note  that,  because  of  the  time  constraint,  only  a  few  employees 
in  Vicksbiirg  were  contacted/interviewed.  A  complete  system  will  need  contribu¬ 
tions  from  everyone,  including  the  customers/clients.  In  addition,  although  the 
personal  interview  method  probably  is  the  best  method  to  “jump  start”  the  sys¬ 
tem  as  reasoned  in  Chapter  2,  organizational  knowledge  and  experience  can  be 
extracted  from  many  other  sources.  A  complete  description  of  knowledge  acqui¬ 
sition,  processing,  and  dissemination  will  be  discussed  in  the  following  section. 


System  Modules 

The  proposed  system  includes  three  basic  modviles:  acqioisition,  processing,  and 
dissemination  of  information.  This  section  will  describe  the  techniques  and 
approaches  for  each  module. 
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Because  the  proposed  system  contains  not  only  OEs  but  also  project  information, 
the  OEs  and  project  information  will  both  go  through  the  three  modules. 
However,  different  techniques  and  approaches  will  be  used  in  each  module  for 
each  type  of  data  because  of  the  differences  in  their  requirements.  The  OEs, 
which  are  the  focus  of  the  proposed  system,  will  need  to  be  systematically 
captured,  processed,  and  disseminated.  On  the  other  hand,  the  project  informa¬ 
tion,  which  is  somewhat  static  and  readily  available,  will  require  much  simpler 
techniques  and  approaches.  The  components  of  the  modules  for  both  project 
information  and  OEs  will  be  described  separately. 

Modules  for  Projected  Information 

Acquisition  of  project  information.  The  acquisition  process  starts  with  contacting 
each  Division  and  customer  to  find  out  what  project  information  they  need.  This 
step  can  be  taken  concurrently  with  the  interview  to  collect  OEs  as  was  done  in 
the  development  of  the  system  prototype.  When  the  list  is  established,  data 
collection  will  be  fairly  simple  because  most  information  related  to  a  project  is 
already  documented  and  available  somewhere  within  the  District.  Some  specific 
data  and  knowledge  (i.e.,  the  history  of  a  river)  might  be  hard  to  get.  However, 
besides  available  written  documentation,  this  information  can  be  collected  by 
interviewing  veteran  personnel  and  locals  who  have  worked  or  Kved  in  the  area 
for  a  long  time.  The  collected  information  shoiild  not  be  limited  to  text  but 
should  also  include  maps,  sketches,  drawings,  pictures,  video  clips,  etc. 

The  initial  efforts  should  result  in  a  majority  of  the  project  information  being 
captmed.  The  project  information  can  be  expanded  to  include  additional  infor¬ 
mation  requested  by  employees. 

Processing  of  project  information.  Most  of  the  project  information  is  validated 
documentation,  so  processing  of  the  project  information  is  fairly  simple. 
However,  project  information,  especially  any  data  collected  fi'om  the  interview, 
should  be  reviewed  for  accuracy  and  suitability  before  being  incorporated  into 
the  system. 

In  addition,  project  information  needs  to  be  categorized,  structured,  and 
presented  in  a  manner  that  allows  fast  and  easy  retrieval  by  anyone  wishing  to 
benefit  from  the  knowledge  base. 

In  the  OKBank  system,  described  in  Chapter  4,  the  focus  is  on  specific  know¬ 
ledge  that  relates  to  a  certain  geographic  area.  For  that  reason,  the  project 
information  is  organized  aroimd  six  main  rivers  within  the  \ficksburg  District’s 
jurisdiction:  the  Mississippi,  Red,  Pearl,  Quachita,  Ibnsas,  and  Yazoo  rivers.  A 
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variety  of  projects  are  associated  with  each  river.  Each  of  these  projects  might 
stretch  across  several  states  and  might  contain  a  series  of  work  items  (individual 
construction  projects).  Each  work  item  or  individual  construction  project  nor¬ 
mally  falls  within  a  jxirisdiction  of  a  local  authority  because  of  the  requirement 
for  local  cooperation  (including  cost  sharing).  The  project  information  is  struc¬ 
tured  based  on  this  breakdown.  Using  the  collected  data  on  the  Red  River 
Levees  project  for  the  system  prototype,  Figure  3  illustrates  how  the  project 
information  is  organized. 

Figure  3  represents  the  typical  data  structure  for  project  information.  The 
details  will  vary  from  one  project  to  another. 

Dissemination  of  project  information.  The  project  information  captured  is  genersd 
information  and  might  benefit  both  the  Corps’  employees  and  customers,  and  the 
general  public.  Therefore,  the  information  should  be  disseminated  as  widely  as 
possible.  However,  because  it  is  hard  to  know  who  needs  what  and  when,  only 
electronic  means  with  search  capabilities  are  recommended. 


Figure  3.  Data  structure  of  project  information. 
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Project  information  update.  Although  the  project  information  is  fairly  static,  some 
data  will  need  to  be  updated  or  deleted.  For  the  proposed  system,  it  is 
recommended  that  certain  project  information  such  as  project  status,  upcoming 
works,  etc.,  be  reviewed  monthly  to  keep  the  system  current.  Other  periodic 
information  such  as  cost  data  and  flood  reports  should  be  updated  as  soon  as  new 
reports  are  generated. 

Modules  for  Lessons  Learned 

Acquisition  of  iessons  iearned.  A  major  number  of  OEs  can  be  collected  initially 
using  the  same  personal  interviewing  approach  used  in  the  development  of  the 
system  prototype.  For  a  complete  system,  the  interview  process  (especially  the 
initial  contacts  phase),  should  be  expanded  to  cover  as  many  employees  and 
customers  as  possible.  It  is  understandable  that  not  everyone  will  be  able  to 
contribute  to  the  system;  however,  employees  being  contacted  will  at  least  know 
about  the  proposed  system  and  might  be  able  to  contribute  in  the  futxire. 

Besides  personal  interviews,  there  are  many  other  sources  from  which  OEs  can 
be  generated.  Change  orders,  contractor  claims,  value  engineering  change 
proposals  (VECPs),  design  reviews  comments,  accident  reports,  and  other  official 
reports  are  soxirces  that  can  be  screened  for  applicable  items.  While  collecting 
these  items,  it  is  important  to  ensure  that  sufficient  information  is  available  to 
tmderstand  the  items  and  their  solutions.  The  information  might  include 
sketches,  drawings,  pictures,  video  clips,  etc. 

Personal  interviews  and  screening  of  existing  documents  should  result  in  a 
significant  number  of  potential  OE  items.  The  initial  knowledge  base  can  be 
continuously  supplemented  by  using  an  input  form  which  shall  be  available  in 
electronic  form.  The  format  of  the  input  form  wfil  be  described  in  Chapter  4. 

Processing  of  organizationaf  experiences.  All  potential  OE  items  will  be  reviewed 
for  acciiracy,  suitability,  and  completeness  before  being  incorporated  into  the 
system.  The  item  originator  will  be  contacted  to  acknowledge  the  receipt  of  the 
item  or  to  request  additional  information  if  needed. 

Similar  to  project  information,  the  approved  OE  items  wiU  be  organized  to  allow 
fast  and  easy  retrieval  by  multiple  parameters.  Because  the  proposed  system 
will  be  designed  for  use  throughout  all  phases  of  the  project  life  cycle  and  across 
multiple  disciplines,  the  OEs  wiU  be  classified  around  major  offices/divisions 
where  the  lessons  are  generated  and  can  be  applied  (e.g.,  engineering, 
construction,  O&M,  etc.).  Major  projects,  individual  contracts,  and  specification 
sections  will  be  used  to  indicate  more  specific  information  if  applicable.  Other 
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alternative  means  of  information  access  such  as  project  location,  associated  life- 
cycle  stages,  and  key  words  are  also  available. 

The  search  and  navigation  features  of  the  proposed  system  will  be  discussed 
further  in  Chapter  4. 

Dissemination  of  organizationai  experiences.  OEs  are  information  that  will  beneSt 
the  entire  organization.  Whether  they  should  be  disseminated  outside  the 
organization  is  a  management  decision  not  discussed  in  this  study.  However,  the 
OEs  should  be  disseminated  as  widely  as  possible  within  the  organization,  and 
OEs  from  one  District  should  be  shared  with  other  Districts.  Both  electronic  and 
non-electronic  means  should  be  vised  for  dissemination. 

Organizational  experience  update.  The  OEs  database  will  need  to  be  monitored, 
maintained,  and  updated  regularly.  The  database  shovild  contain  only  apphcable 
and  current  items.  Items  that  are  obsolete  or  no  longer  apphcable  will  need  to  be 
deleted.  The  database  should  be  periodically  reviewed  for  items  that  can  be 
incorporated  into  guide  specifications,  design  criteria,  standard  procedvires, 
policies,  and  regulations  so  the  organization  can  learn  as  a  whole.  In  addition, 
those  items  that  are  incorporated  may  be  removed  from  the  database,  making 
the  system  easier  to  manage.  New,  valid  items  shovild  be  added  to  the  database 
as  soon  as  possible  so  employees  can  benefit  from  them  immediately. 

Computer  Technology 

None  of  the  above  processes  can  be  effectively  completed  without  a  computerized 
system.  The  fundamental  goal  of  the  proposed  system  is  to  capture  organi¬ 
zational  knowledge  and  experience  for  retrieval  and  use  later.  The  automated 
system  will  be  a  fast  and  efficient  tool  for  captviring,  processing,  and 
disseminating  the  information.  The  selection  of  software  for  this  system  will  be 
discussed  in  the  next  section. 


Software  Selection 

.  Many  major  research  efforts  and  studies  have  been  done  to  determine  the  best 
software  tools  for  a  system  that  can  automatically  captvire,  process,  and  dis¬ 
seminate  OEs.  Most  of  the  developers  of  the  latest  systems  also  agreed  that  the 
best  mechanism  for  integration  of  OEs  is  through  the  Internet.  A  multimedia 
system  was  also  strongly  recommended  for  enhancing  the  application  of  OEs. 
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One  of  the  major  extensive  efforts  was  the  study  done  by  CII  and  the  University 
of  New  Mexico  (Fisher  1997).  This  study  suggested  a  list  of  attributes  that  an 
ideal  software  package  should  have  for  a  multimedia  system.  Table  3  sum¬ 
marizes  this  hst. 


Table  3.  Summary  of  attributes  of  ideal  software  tools. 


Phase* 

Attribute 

Explanation 

1 

Network-based 

Ensures  organization-wide  multiple  access  points.  Should  use  a 
commonly  used  protocol  to  facilitate  access  outside  the 
organization. 

C 

Open  system 

Contributions  from  anyone  should  be  possible.  Anonymous 
logins  should  be  possible.  An  *all  accepting*  system. 

C 

Narrative  and 
structured  input 

To  support  varying  experiences  and  ease  of  screening  the 
input. 

m 

Multimedia 

Makes  use  of  human  senses  to  avoid  overload  on  a  single  one. 
Simplifies  perception  and  lessens  cognitive  load. 

1 

Database 

A  relational,  heterogeneous,  distributed  multi-database  for 
organized  storage  and  guick  retrieval  of  knowledge. 

1 

Navigation  and  search 

Effective,  user-oriented  retrieval  of  stored  information. 
Chronological,  theme  searches  to  augment  traditional  key-word 
searches.  Situational  data  guarantees  user-oriented  information 
seeking  without  overwhelming  the  user  with  irrelevant 
information. 

m 

Security 

No  unauthorized  access.  Authenticated  and  encrypted 
communication.  Preservation  of  integrity  of  stored  information. 

l.Co 

Administration  and 
management 

Centralized  or  distributed  management  should  be  possible. 

High  level  interface  designed  for  nonprogrammer 
administrators. 

A 

Decision  support 

Semi-automated  screening,  sorting,  and  classification  of 
information  for  determining  validity  of  information  to  be  entered 
in  the  storage. 

C.  1,  Cul 

Informal 
communication, 
collaboration,  and 
appreciation  platform 

The  tool  can  act  as  a  “town-hall"  where  members  of  the 
organization  can  communicate  informally  because  an 
organization  learns  a  lot  (i.e.,  through  E-mail,  bulletin  board, 
chat  channels,  etc.)  Appreciation  on  this  platform  will  provide 
an  incentive  for  further  participation. 

1 

Solicited  and 

unsolicited 

dissemination 

A  user  should  be  able  to  get  additional  (and  available) 
information  upon  request.  A  user  must  receive  some  information 
by  virtue  of  his/her  function,  despite  personal  choice,  in  the 
organization’s  interest. 

Ail 

Designed  for  human 
interaction 

User-friendly  system.  Matches  virith  users,  their  tasks,  cognitive 
and  physical  capabilities,  and  their  social  aspirations.  Interface 
designed  with  users'  tasks  in  mind  and  helps  them  carry  out  the 
task  in  a  manner  seamless  to  their  everyday  work. 

I.A 

Usage  tracking 

This  can  help  to  determine  usability  (hence  returns)  of  the 
system.  Usage  patterns  can  be  used  to  selectively 
modify/amend  the  system. 

Co 

Cost 

Lower  initial  costs  are  desirable.  Hard  dollar  returns  on 
knowledge  systems  are  bften  hard  to  judge;  hence,  the 
system’s  usability  is  difficult  to  show. 

Co 

Speed 

Should  not  test  user’s  patience  and  lose  the  interactive  nature. 
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Phase* 

Attribute 

Explanation 

Co 

Extensibility  and 
development  tools 

Should  be  designed  for  modifications/extensions  in  future. 

Shouid  provide  tools  to  carry  out  such  modifications  or  develop 
the  system  further  for  customization. 

I.Cul 

Social  activity 
indicators 

Seeing  that  others  are  using  the  system  will  prompt  more 
people  to  use  it.  Solution  to  the  problem  of  ‘critical  mass"  to  get 
the  system  going  upon  start-up. 

1.  Cul 

Human  extension  of 
knowledge  base 

To  tap  into  the  organization’s  social  network  (individual 
expertise)  in  the  case  stored  knovirledge  does  not  solve  a 
problem. 

All 

User  Support 

Unobtrusive,  accurate,  robust,  consistent,  and  flexible  help 
system.  Searchable  and  context-sensitive  on-line 
documentation.  On-line  tutorials  for  training. 

*C  =  Collection,  A  =  Analysis,  I  =  Implementation,  Co  =  Coordination,  Cul  =  Culture. 
(Source:  Fisher  1997.) 


Another  major  effort  was  the  development  of  DrChecks  by  USACERL.  This 
system  is  one  of  the  latest  developments  on  the  topic.  It  took  the  advantages  of 
the  WWW  and  other  relational  software  programs  in  effectively  capturing, 
processing,  and  disseminating  OEs.  This  approach  is  realistic  and  useful  in 
integrating  the  capture  and  use  of  OEs.  DrChecks  is  fully  developed  and  under 
official  testing  for  implementation. 

Although  DrChecks  was  specifically  developed  for  use  in  facility  constniction  by 
designers  during  the  design  review  process,  it  has  many  ideal  attributes 
recommended  by  CII.  For  a  detailed  description  of  the  software  tools  used  in  the 
development  process  of  DrChecks,  refer  to  system  reviews  in  Chapter  2.  Table  4 
compares  the  DrChecks  software  tools  against  the  ideal  tools  recommended  by 
CII. 

The  comparison  in  Table  4  indicates  that  the  software  tools  used  in  DrChecks  are 
very  close  to  the  ideal  software  tools  recommended  by  CII.  This  reason  alone 
suggests  that  the  same  software  should  be  used  for  the  development  of  the 
system  prototype.  Furthermore,  by  selecting  a  software  package  that  has  been 
developed  and  tested  for  other  types  of  U.S.  Army  Corps’  projects  (i.e.,  military 
construction),  the  initial  development  cost  and  time  will  be  reduced 
tremendously. 

It  is  important  to  remember  that  DrChecks  focuses  on  the  design  review  process. 
The  system  captures  OEs  that  are  technically  oriented.  It  is  textual  based  and 
does  not  include  other  multimedia  data  such  as  graphics,  video  clips,  etc. 
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Table  4.  DrChecks’  software  tools  vs.  Oil’s  Ideal  software  tools. 


ideal  Attribute 

DrChecks 

Remarks 

Network-based 

Yes 

The  Internet  platform  ensures  organization-wide  multiple 
access  points. 

Open  system 

Yes 

During  the  official  test  period,  some  restriction  is  imposed. 
However,  contribution  from  anyone  is  possible. 

Narrative  and  structured 
input 

Yes/No 

The  input  is  fairly  structured  because  its  primary  focus  is 
for  use  by  designers  in  the  design  review  process. 

Multimedia 

No 

Although  the  system  has  the  capability  to  support 
multimedia,  currently  DrChecks  contains  only  text. 

Database 

Yes 

Microsoft  Access  2.0  is  a  relational,  heterogeneous, 
distributed  multidatabase. 

Navigation  and  search 

Yes 

Search  selection  criteria  in  DrChecks  include  but  are  not 
limited  to  the  following;  keywords,  location,  specification 
number,  and  the  issue  category  of  design,  construction,  or 
operations. 

Security 

Yes 

DrChecks  requires  passwords  for  accessing  certain 
information. 

Administration  and 
management 

Yes/No 

DrChecks  is  centrally  managed  by  a  system  administrator. 

Decision  support 

Yes 

DrChecks  has  mechanism  for  semi-automated  screening, 
sorting,  and  classification  of  information  for  determining 
validity  of  information  to  be  entered  in  the  storage. 

Informal  communication, 
collaboration,  and 
appreciation  platform 

Yes 

E-mail  is  used  in  DrChecks  for  informal  communication. 

Solicited  and  unsolicited 
dissemination 

Yes 

Users  can  get  additional  (and  available)  information  upon 
request.  This  practice  has  long  been  part  of  the  culture 
of  the  Corps. 

Designed  for  human 
interaction 

Yes 

DrChecks  is  designed  with  users'  tasks  in  mind  and  helps 
them  carry  out  the  task  in  a  manner  seamless  to  their 
everyday  work. 

Usage  tracking 

Yes 

DrChecks  tracks  number  of  usage  and  kind  of  users. 

Extensibility  and 
develooment  tools 


Social  activity  indicators 


Human  extension  of 
knowledge  base 


User  Su 


The  exact  actual  system  cost  is  not  available.  However, 
DrChecks  uses  existing  organizational  standardized 
software,  so  its  initial  cost  is  minimal. 


DrChecks  is  desioned  with  speed  in  mind. 


DrCheck  can  be  modified  and  extended  in  future. 


Users  can  contact  the  lesson  originators  or  other  Corps 
experts  anytime  when  stored  knowledge  does  not  solve  a 
roblem. 


ppo 

rt 

No 

There  is  no  on-line  hel 

The  proposed  system  will  be  designed  with  emphasis  on  the  project  life  cycle  and 
will  not  hmit  OEs  to  only  technical  issues.  Multimedia  will  be  used  whenever 
applicable.  Therefore,  many  modifications  wiU  need  to  be  made  to  the  DrChecks 
system  to  accommodate  these  new  requirements.  In  addition,  the  proposed 
system  will  also  contain  project  information  besides  OEs.  This  information  is 
specific  project  information  that  is  geographically  oriented.  The  best  software 
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tool  to  represent  this  type  of  information  is  map-related  software.  In  selecting 
the  map-related  software,  the  emphasis  is  on  their  cost.  Shareware  or 
demonstration  software  will  be  used  whenever  possible.  The  software  tools  used 
in  the  development  and  programming  of  the  system  prototype  will  be  discussed 
further  in  Chapter  4. 
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4  The  OKBank  System 


The  process  of  captiiring,  storing,  and  retrieving  organizational  knowledge  is 
very  similar  to  the  process  of  depositing,  saving,  and  withdrawing  money  from  a 
bank.  For  this  reason,  the  system  was  named  Organizational  Knowledge  Bank 
(OKBank).  As  with  any  “bank,”  the  best  automated  tool  for  performing  many 
“banking  transactions”  has  to  be  the  Automated  TeUer  Machine  (ATM).  The 
ATM  is  probably  one  of  the  automated  machines  that  are  most  familiar  to  and 
most  often  used  by  people.  It  is  imder  this  xiser  interface  concept  that  the 
system  prototype  was  modeled. 


General  Description 

The  basic  component  of  the  OKBank  system  is  a  web  site  that  can  receive  the 
deposit  (submission)  of  experiences  from  the  users.  It  allows  users  to  review  the 
submitted  items  in  the  OKBank  account.  Users  can  also  withdraw  (retrieve) 
helpful  project  information  and  OEs. 

In  general,  a  user  begins  to  xise  the  system  by  accessing  the  homepage  of  the 
OKBank  system.  The  homepage  presents  as  a  screen  similar  to  that  of  an  actual 
ATM.  A  button  bar  on  the  left  side  of  the  screen  contains  common  navigation 
buttons  such  as  home,  back,  up,  help,  about.  This  button  bar  remains  in  place 
throughout  the  system.  Another  button  bar  on  the  right  side  contains  subject/ 
topic  buttons  linked  to  HTML  pages  and  other  menus.  The  right  button  bar 
menu  changes  throughout  the  program  depending  on  the  button  selection. 
Between  the  two  bars,  the  screen  displays  the  information  related  to  the  selected 
topics. 

Because  the  processes  involved  with  the  project  information  are  different  than 
those  associated  with  OEs,  they  will  be  discussed  separately.  The  system  is  best 
described  by  illustrating  the  processes  involved  in  it. 
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Project  Information 

As  discussed  in  Chapter  3,  the  project  information  is  organized  with  a 
hierarchical  approach.  Each  item  in  the  hierarchy  represents  a  specific  topic 
that  contains  information  related  to  that  topic.  The  information  is  electronically 
stored  in  a  series  of  HTML  pages.  Each  topic  or  subtopic  is  represented  by  a 
button  on  the  right  button  bar  menu,  which  is  hard  linked  to  the  HTML  pages. 
Figure  4  further  illustrates  this  configuration. 


OKBankn 
System  Description 


Mississippi  R.  Red  River{*)  Ouachita  R.  Pearl  River  Tensas  River  Yazoo  River 


Projects 


aeneral  Project  Informatloi 


Projects 


Projects  ^Projects  ^ 

Red  River  Levees(*) 

-  Overall  Project  Status(*) 

-  Upcoming  Works(*) 

^  —Flood  Emergency  Assistance(*) 
—  Flood  Reports(*) 

-  Flood  Fight  Methods(*) 

-  Applicable  Regulations{*) 


Projects 


Projects 


Typical  X-Section(*) 
Historical  Cost  Data 
As-built  Drawings 
Inspection  Reports(*) 
Permitting 

Other  Specific  Information 


(*)  =  Indicates  HTML  pages  that  contain  data 

Figure  4.  Configuration  of  project  information  in  the  OKBank. 
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The  project  information  HTML  pages  contain  text,  graphics,  and  image  maps. 
They  were  created  using  the  following  software  tools:  Homesite™,  Deskscan  II™, 
PaintShop™,  and  MapThis™.  Homesite  was  used  to  create  standard  HTML 
pages;  Deskscan  II  for  scanning  maps,  pictures,  sketches,  drawings,  and  text; 
PaintShop  for  constructing  the  images;  and  MapThis  to  make  image  maps. 
Demonstration  versions  of  most  of  these  tools  are  available  via  the  Internet. 

Any  user  can  access  the  project  information  contained  in  the  OKBank.  The 
project  information  can  be  accessed  by  clicking  the  appropriate  buttons. 

Users  can  also  search  for  information  using  key  words.  Begin  the  search  by 
clicking  on  the  “site  search”  button  on  the  right-hand  button  bar.  The  search  will 
find  every  indexed  page  that  contains  the  key  words.  This  search  mechanism  is 
provided  by  the  Verity  search  engine. 


Organizational  Experiences 

OEs  are  the  main  part  of  the  OKBank  system.  They  share  the  same  web  site 
with  the  project  information.  However,  the  processes  associated  with  the  OEs 
also  require  other  major  components.  These  components  and  the  general  flow  of 
the  OEs  are  described  below. 

The  user  begins  a  query  through  a  form  action  contained  in  the  HTML  page. 
The  web  server  receives  the  query  and  executes  another  web  page  called  the 
template  file,  which  contains  both  HTML  and  script  formatting  tags.  Based  on 
the  scripting  information  contained  in  the  template  file,  a  query  is  posted  to  the 
script  processing  program.  The  script  processing  program  is  provided  by  the 
Allire  Corporation’s  Cold  Fusion™  product  and  uses  a  set  of  HTML  extensions 
called  Cold  Fusion  Markup  Language  (CFML). 

The  query  is  then  posted  to  the  data  source,  Microsoft  Access™  database  (version 
7.0),  where  the  result  of  the  query  is  returned  or  other  actions  are  taken.  Based 
on  the  formatting  information  provided  in  the  template  file,  query  results  are 
returned  and  an  HTML  document  is  produced.  The  resiilting  page  is  provided  to 
.  the  user  through  the  web  server.  Figure  5  further  illustrates  the  flow  of 
information. 
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(Source:  East  1996.) 

Figure  5.  General  Flow  of  Organizational  Experiences. 


The  OKBank  ATM  is  designed  as  an  “open”  system  so  that  it  can  benefit  as  many 
users  as  possible.  However,  the  OKBank  ATM  will  require  a  Personal 
Identification  Number  (PIN)  in  certain  processes  where  the  database  could  be 
compromised.  This  secmity  mechanism  is  built  into  OKBank  so  that  only 
authorized  individuals  can  update  and  delete  items  fi*om  the  database. 
Situations  where  the  PINs  are  required  will  be  identified  throughout  the 
following  discussion  of  processes. 

Deposit  an  Item 

The  user  can  begin  to  deposit  (submit)  an  item  by  clicking  on  the  “deposit” 
button  in  the  right-hand  button  bar  of  the  OKBank  ATM.  A  deposit  form  will  be 
displayed.  The  deposit  form  has  spaces  for  narratives  and  multiple-choice 
answers.  It  also  has  a  field  for  the  user  to  upload  related  text  files  or  image  files 
(sketch,  drawing,  pictures,  etc.).  The  image  file  must  be  in  “GIF”  format.  This 
feature  is  currently  under  development.  The  form  is  divided  into  three  parts: 
general  information,  description,  and  recommendations.  Each  part  has  certain 
required  optional  fields.  The  fields  for  each  part  are  listed  in  Tables  5, 6,  and  7. 

After  the  user  has  completed  the  form,  he/she  can  press  the  “submit”  button  at 
the  end  of  the  form.  A  “reset”  button  clears  values  on  the  form.  The  format  of 
the  deposit  form  is  depicted  in  Figure  6.* 


*  Figures  6  through  1 0  can  be  found  at  the  end  of  the  chapter,  beginning  on  p  41 . 


Table  5.  General  Information  (Part  1). 


Field 

Required 

Selection  List 

Division/Office 

Yes 

Planning 

Project  and  Program  Management 

Real  estate 

Engineering 

Contracting 

Construction 

Operation  &  Maintenance 

Other 

Project  (these  are 
projects  that  contain 
several  individual 
contracts) 

No 

Red  River  Levee  and  Bank  Stabilization 

Red  River  Emergency  Bank  Protection 

Red  River  Waterways 

Other 

Emergency 

Operations 

No 

Flood  fight 

Flood  reports 

Emergency  assistance 

Other 

Regulatory  Issues 

No 

Wetlands 

Waterways 

Levees 

Other 

Contract  Name 

No 

User  inputs 

Customer 

No 

User  inputs . 

City 

No 

User  inputs 

Author 

Yes 

User  inputs 

Author’s  Phone 

Yes 

User  inputs 

Author’s  Email 

No 

User  inputs 

Table  6.  Description  (Part  2). 


Field 

HEiscnzsiii 

Selection  List 

Yes 

User  Inputs 

Type  of  Issue 

Yes 

Success  story 

Good  work  practice 

Potential  error 

Potential  omission 

Possible  oversight 

Coordination 

Safety 

Other 

Occur  During 

Yes 

Planning 

Programming 

Design 

Procurement 

Construction 

Operations  &  Maintenance 

Rehabilitation 

Other 

Specification  No. 

No 

User  inputs 

Related  Discipline 

No 

Architecture 

Civil 

Electrical 

Environmental 

Geotechnical 

Mechanical 

Structural 

Other 

Describe  Problem 

Yes 

User  inputs 

No 

User  inputs 

USACERL  SR  98/64 


39 


Table  7.  Recommendations  (Part  3). 


Field 

Selection  List 

Recommended 

Solution 

Yes 

User  inputs 

Benefits 

expected/realized 

Yes 

Cost  savings 

Time  savings 

Quality  improvement 

Customer  satisfaction 

Environmental  sustainability 

Hazard  reduction 

Other 

Review  Items 

After  an  item  has  been  submitted,  it  is  stored  in  the  database  pending  review. 
The  reviewer  is  a  person  or  persons  designated  by  management  to  take  action  on 
the  submission.  The  reviewer  can  start  the  review  process  by  clicking  the 
“account”  button  on  the  right-hand  button  bar.  The  reviewer  will  be  prompted 
for  a  “PIN.”  After  the  correct  PIN  is  provided,  the  reviewer  will  be  presented 
with  a  list  of  pending  items.  Figure  7  shows  the  list  of  pending  items.  Notice 
that  only  subjects  or  short  titles  are  shown. 

Tb  take  action  on  any  of  the  pending  items,  the  reviewer  can  click  the  title  to 
access  the  full  set  of  data  available  for  that  item.  Figure  8  shows  an  item’s 
detailed  data  screen. 

The  reviewer  is  not  permitted  to  edit  the  author's  item.  The  reviewer  can, 
however,  update  the  status  fields  of  the  comment  record  to  provide  feedback  on 
the  status  and  final  disposition  of  each  lessons-leamed  item.  This  comment 
record  is  located  at  the  bottom  of  the  detailed  data  screen  (Figure  8).  Figure  9 
shows  the  pending  item  update  form.  Once  the  reviewer  has  evaluated  the  item, 
he/she  will  either  approve  or  disapprove  it.  If  the  item  is  approved,  it  will  be 
ready  for  retrieval.  Otherwise,  it  will  be  removed  from  the  database. 

Withdraw  Items 

Users  can  find  approved  items  by  first  clicking  on  the  “withdraw”  button  on  ttie 
right-hand  button  bar.  The  user  will  be  presented  with  a  search  page  (Figure  10) 
that  includes  several  criteria.  The  search  criteria  include:  offices/divisions, 
project,  emergency  operations,  regulatory  issues,  contact  name,  customer,  city, 
author,  subject/short  title,  type  of  issue,  associated  phase,  specification  ntunber, 
related  discipline,  benefits  expected/realized,  and  key  words.  Users  can  select 
any  of  these  criteria  or  any  combination  of  criteria  for  sesirching. 
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Figure  11  shows  an  example  of  the  results  of  the  search  presented  to  the  user. 
Users  can  click  on  the  title  of  the  item  foimd  to  see  the  full  details  of  an  item. 
The  detailed  screen  of  a  found  item  is  similar  with  the  screen  depicted  in  Figure 
8. 

Users  can  also  search  for  approved  items  in  the  OKBank  using  key  words  or 
phrases  similar  to  the  search  for  project  information.  This  search  feature  will 
allow  the  users  to  search  for  approved  items  in  the  OEs  database  without  having 
to  navigate  through  the  above  screens. 

The  previous  three  sections  provided  a  complete  description  of  the  system 
prototype.  However,  remaining  issues  such  as  system  security,  system  admini¬ 
stration  and  management,  and  system  integration  will  need  to  be  addressed 
before  the  system  can  be  implemented.  These  are  management-related  issues, 
which  are  outside  the  scope  of  this  investigation.  However,  each  of  these 
concerns,  along  with  the  recommended  solutions,  will  be  briefly  discussed  in 
Chapter  5. 
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You  may  make  a  deposit  of  a  success  story,  gqod  work  practice,  or  lessem  learned  udng  ^  ' 

below.  Note  that  not  all  items  are  required  for  your  submission  to  ^  cu^ceptedl^ea^  :k!ect  the  most 
appropriate  itemfiom  ail  r  elated  pick  !i^s:  Qni^sidmiihdyfrourtteni^nj^ 

Wilt  hi!?  yyanAo  €rY!?  fh/SK^ 


Diwsioi^fBce:  ^  J  (re  q  u  I  re  d) 

Pp^ct:  ^  (optional] 

EmeipiayybpeiatioiB:  [optional] 

Ri^^toxylssTies:,^  /  (optional] 

“/  '*  ;  s  .  I . — 

Coi&tNazne:  Vr  ;;  (optional] 


C^toj^r ■''*  ■.:  |  (optional] 


(optional] 


(required] 


(required) 


S^tek  to  t^ad  (gif): 


'  Part  3.  Recominft  Atioiis 
R^mmendwi  Solntibii:  h 


(optional] 


nu^ndatipz.:  ^  -IF^V  ■ 


’^'.'n-Submit'' 


Figure  6.  Deposit  submittai  form. 
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OKBank  ATM  -  Microsoft  Internet  Explorer 


File  Edit  View  Go  Favorites  Help 


;';:,0\ 

.  ; '. 

0 

aT:’;'  #  " 

m^ 

:V  ’  Back 

.  Forwatid  r 

Stop 

Refresh 

Home 

Search  ^ 

Favorites  '  Print  ■ 

f  ^Fpn 

iJI  Addess  http:  //east,  cecer,  army,  mil/okbank/lessons/accounts.cfm 


I  LMs 


'■4-. 

•*  i 


ArJ:r^:hh^ 


I 


lYiQrgan-a^-Ai 


-TJse  a  button  to  me  left  oftheiicreen  to  return  tome  top^ofmeiPl^anfcpro^a^^ 

' ,  *  Use  your  browser's  back'key  to  scrol bacics‘ilro^^ti^^^es^^a^^L6^'d;j'^4S%''r ! /' 
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page  and  submityouireview’JYQUffiust also  proviileyotj^lN^wtibertHat’aumiQazesyou to  ■ 
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Figure  10.  The  withdraw  (search)  screen 
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1*  N  vV-  "'i5  ,  'V 


Figure  11.  List  of  items  found. 
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5  Review,  Recommendations,  and 
Conclusion 


This  chapter  is  a  final  overview  of  the  research  effort,  including  a  review  of  the 
original  research  objectives.  It  will  also  include  recommendations  for  future 
enhancements  to  the  OKBank  prototype  system. 

Part  of  the  recommendations  will  focus  on  implementation  issues  such  as  system 
security,  data  management  (gate  keeping),  and  system  integration  mentioned  in 
Chapter  4. 


Review  of  Original  Objectives 

The  original  overall  objective  of  this  research  was  to  develop  an  automated 
system  that  can  capture,  store,  and  disseminate  lessons  learned  fi’om  all  project 
participants,  throughout  all  phases  of  the  project  life  cycle  in  a  civil  works 
organization.  The  overall  objective  was  broken  down  into  several  specific 
objectives. 

Objective  No.  1  was  to  investigate  and  review  the  most  significant  automated 
lessons  learned  systems.  This  task  was  accomplished  by  reviewing  published 
literatm-e  and  contacting  experts  in  the  field.  Many  systems  were  identified,  but 
only  six  systems  are  available.  These  six  systems  were  thoroughly  reviewed  as 
described  in  Chapter  2,  which  also  contains  highlights  and  specific  features  of 
each  system.  In  addition,  some  other  major  research  efforts  were  also  studied. 
These  efforts  provided  many  good  concepts,  a  fi*amework,  and  recommendations 
for  an  automated  lessons  learned  system. 

.  Objective  No.  2  was  to  identify  the  deficiencies  of  these  systems  within  the 
context  of  civil  works  projects,  with  an  emphasis  on  the  project  life  cycle.  An 
evaluation  guideline  was  developed  to  assist  in  achieving  this  task.  It  was 
concurrently  performed  with  Objective  No.  1.  The  results  are  also  indicated  in 
Chapter  2. 

Objective  No.  3  was  to  collect  sample  data  for  system  development  and  to  design 
the  system.  Because  the  system  is  designed  to  cover  all  phases  of  the  project  life 
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cycle,  a  major  levee  project  was  selected  for  sample  data  collection  purposes.  The 
data  collection  process  was  accomplished  by  rosing  the  personal  interview 
approach.  It  is  interesting  to  note  that  the  interviews  not  only  resulted  in  data 
for  the  system,  but  also  caused  a  shift  in  the  system’s  design.  The  system  was 
originally  intended  to  contain  only  lessons  learned.  However,  the  responses  from 
the  interviewees  indicated  that  geographically  oriented  project  information 
should  also  be  included  in  this  system.  The  design  was  then  modified  to  include 
applicable  project  information  in  addition  to  lessons  learned.  Furthermore, 
although  many  system  developers  have  tried  to  define  lessons  learned  as  both 
positive  and  negative  experiences,  the  term  “lesson  learned”  itself  inherently 
projected  a  negative  image.  Becaxise  this  system  was  designed  to  capture 
experiences  of  an  organization,  the  term  “organizational  experiences”  seemed 
more  appropriate.  It  was  determined  that  the  term  “organizational  experiences” 
would  replace  the  term  “lessons  learned”  in  the  system.  This  task  was  completed 
as  described  in  Chapter  3. 

Objective  No.  4  was  to  program  the  prototype  system.  This  task  was  probably 
the  most  ambitious  and  difficult  of  all  the  objectives.  One  of  the  biggest  factors 
was  the  time  constraint.  Fortunately,  USACERL  provided  programming 
support.  The  result  is  the  OKBank  system  described  in  Chapter  4.  The  OKBank 
system  can  be  visited  through  the  Internet  at  http://east.cecer.army.mil/okbank/. 

The  review  indicated  that,  in  general,  all  original  objectives  were  accomplished. 
However,  since  the  main  purpose  of  the  OKBank  system  is  to  help  the 
organization  to  continuously  improve,  the  system  itself  should  also  be  improved 
upon  primarily  through  feedback  from  the  users. 


Implementation  Issues 

Future  Enhancement  to  the  Submittal  and  Search  Forms 

The  submittal  and  search  forms  used  for  depositing  and  withdrawing  OEs  in  the 
OKBank  system  £u*e  fairly  long  because  they  are  designed  to  be  used  by  all 
project  participants,  across  multiple  disciplines,  throughout  all  phases  of  the 
project  life  cycle.  Although  most  of  the  input  fields  are  multiple  choice  and  many 
fields  are  optional,  the  long  forms  might  discourage  people  from  participating.  It 
would  be  very  difficiilt  to  simplify  these  forms  at  this  time  because  of  the 
possibility  of  certain  important  fields  being  left  out.  After  the  system  is  in 
operation  for  awhile,  these  forms  can  be  monitored  and  reviewed  for  certain 
usage  patterns.  Fields  that  are  never  used  can  be  deleted  from  the  forms.  Other 
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fields  that  are  seldom  used  can  be  combined.  The  simpler  forms  will  require  less 
effort  from  the  user.  Consequently,  the  system  will  be  used  more  often. 

Security 

As  described  throughout  Chapter  4,  the  OKBank  system  prototype  is  designed  so 
that  any  user  can  withdraw  information,  including  OEs.  Any  user  can  also 
submit  an  OE  item.  No  PIN  is  required  for  these  processes.  The  PIN  is  only 
required  in  the  review  and  approval  process. 

While  working  level  employees  and  the  customers  prefer  an  “open”  system, 
management  might  not  want  to  share  certain  information  with  the  general 
public.  This  concern  is  valid  if  the  information  is  classified  and  sensitive.  In  the 
case  of  a  civil  works  organization  such  as  the  "Vicksburg  District,  all  information 
(including  OEs)  related  to  a  project  are  generally  pubHc  records.  In  addition,  as 
discussed  before,  civil  works  projects  involve  many  stakeholders,  including  the 
general  public.  The  OEs,  as  broadly  defined  in  the  OKBank  system,  including 
items  such  as  successful  flood  fighting  methods,  may  also  benefit  the  general 
public.  Therefore,  it  wovild  be  senseless  to  restrict  the  system  to  internal  use 
only.  After  aU,  through  the  review  and  approval  process,  management  stall  has 
the  final  say  on  what  information  will  be  permanently  stored  for  retrieved. 

In  the  current  version  of  the  OKBank,  any  user  can  submit  an  item  to  the 
system.  This  accessibility  has  raised  some  concerns  about  inappropriate 
submissions.  Improper  items  may  be  submitted  into  the  system.  However,  this 
drawback  is  small  compared  to  the  advantages  of  a  fuUy  open  •system.  The 
system  needs  contributions  fi'om  everyone.  An  open  system  will  increase  the 
opportunities  for  submission,  and  the  reviewers  can  always  delete  invalid  items. 

For  these  reasons,  the  “open”  system  concept  used  in  the  prototype  shall  also  be 
used  for  the  implementation  of  the  OKBank  system  in  \Tcksbvirg  District; 

System  Gatekeeping 

For  this  system  to  serve  effectively,  the  database  will  need  to  be  properly 
maintained  and  managed.  Authorizing  access  to  the  database,  reviewing  or 
coordinating  the  reviewing  process,  and  updating  the  database  are  just  some 
duties  required  of  the  gatekeeper.  The  two  approaches  in  handling  these  duties, 
centralized  and  distributed  gatekeeping,  are  described  below. 

Centralized  gatekeeping.  The  centralized  gatekeeping  method  is  used  quite  often, 
especially  in  new  systems.  This  approach  requires  a  gatekeep>er  to  perform  all 
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the  gatekeeping  functions.  The  gatekeeper  monitors  the  database.  If  an  item  is 
pending  for  review,  the  gatekeeper  will  either  review  the  item  or  consult  with  the 
appropriate  expert  for  assistance.  The  gatekeeper  then  takes  appropriate 
actions.  If  the  item  is  approved,  it  wiU  be  ready  for  retrieval.  Otherwise,  the 
gatekeeper  will  remove  it  from  the  database.  Figure  12  further  illustrates  this 
centralized  gatekeeping  approach. 


DATABASE 


Figure  12.  Centralized  gatekeeping. 


The  centralized  gatekeeping  approach  has  many  advantages.  Since  the  gate¬ 
keeper  is  solely  responsible  for  the  data  in  the  system,  he/she  wiU  ensure  that 
the  appropriate  people  review  the  submitted  items  and  the  database  is  kept  up 
to  date.  The  single  point  of  contact  for  coordination  and  commvuuc^tion  wiU  also 
keep  the  information  flowing  smoothly.  The  gatekeeper  can  also  perform  other 
administrative  duties  such  as  providing  technical  support,  upgrading  and 
maintaining  system  hardware  and  software,  etc.  The  biggest  problem  from  this 
approach  is  the  cost.  It  is  estimated  that  it  wiU  take  a  qualified  individual  at 
least  half  time,  if  not  fuU  time,  to  perform  aU  these  functions. 

Distributed  gatekeeping.  In  the  distributed  approach,  each  reviewer  wiU  also 
serve  as  the  gatekeeper  for  the  system.  The  submitted  item  wiU  be  distributed 
automatically  to  appropriate  reviewers  depending  on  predetermined  criteria. 
For  exeunple,  aU  items  generated  by  the  Construction  Division  wfll  be  sent  to  a 
construction  appointee  for  review.  This  person  wiU  automaticaUy  be  notified  by 
some  electronic  means  such  as  e-mail  or  during  log  in.  After  reviewing  the  item, 
the  appointee  will  perform  the  gatekeeper  function  by  changing  the  pending  item 
to  an  approved  item  if  he/she  approves  it.  Otherwise,  he/she  wiU  delete  the  item 
from  the  database.  Figure  13  further  iUustrates  the  distributed  gatekeeping 
approach. 
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Figure  13.  Distributed  gatekeeping. 


The  advantage  of  this  system  is  that  it  will  not  reqviire  a  full  time  employee  to 
perform  the  gatekeeping  function.  However,  submitted  items  might  not  be 
reviewed  promptly  and  the  database  might  not  be  updated,  since  no  one  is 
responsible  and  accountable  for  the  system  database.  Users  will  not  know  where 
to  get  support.  Some  minor  system  administration  will  still  be  required. 


For  the  implementation  of  the  OICBank  system  in  the  Vicksburg  District,  it  is 
recommended  that  the  centralized  approach  be  used  at  least  for  the  initial  phase. 
Because  the  system  is  new,  there  will  be  problems  and  questions.  A  single 
gatekeeper  who  is  responsible  for  the  system  will  be  more  effective  xmder  these 
circumstances.  After  the  organization  becomes  used  to  its  existence  and  feels 
comfortable  about  it,  the  distributed  approach  can  and  should  be  used.  When 
the  distributed  approach  is  used,  some  services  are  still  required  to  keep  the 
system  running  properly.  However,  these  services  are  periodic  and  can  be 
supported  by  personnel  from  an  existing  office  such  as  Information  Management. 

System  Integration  With  Business  Practices 


The  best  automated  system  in  the  world  will  not  and  cannot  make  itself  useful 
unless  the  organization  provides  mechanisms  for  integrating  the  system  into  its 
day-to-day  operations.  Since  the  OKBank  is  designed  for  use  in  all  phases  of  the 
project  life  cycle  and  each  phase  has  its  own  unique  requirements,  it  would  be 
difficult  to  suggest  a  detailed  system  integration.  However,  a  general  system 
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integration  is  recommended.  At  a  minimum,  each  major  division  that  is 
responsible  for  a  phase  within  the  project  life  cycle  should  be  required  to  review 
the  OEs  that  are  applicable  to  their  own  phase.  For  example,  Planning  Division 
should  review  all  experiences  occurring  or  gained  during  the  planning  phase  of 
previous  projects.  At  what  point  during  the  planning  process  the  review  should 
be  done  is  for  the  Planning  Division  to  decide.  Figure  14  further  illustrates  the 
recommended  system  integration. 


Figure  14.  Integration  of  the  OKBank  System  with  business  practices. 


In  the  case  of  Vicksburg  District,  this  requirement  can  be  integrated  with 
policies  or  procedures  governing  the  processes  involved  in  each  phase  of  the 
project  life  cycle.  For  example,  the  Engineering  Division  is  responsible  for  the 
design  phase  of  any  project.  The  design  phase  includes  a  design  review  process. 
As  part  of  the  design  review  process,  the  design  team  member  is  required  to 
complete  a  Design  Team  Review  Checklist.  The  review  of  design-related 
experiences  contained  in  the  OKBank  system  should  be  added  to  this  checklist 
as  a  task  to  be  completed.  This  addition  will  ensure  that  the  design  team 
member  will  review  the  OEs  gained  during  the  design  phase  of  previous  projects. 

Other  major  divisions  responsible  for  other  phases  such  as  Planning,  Contract¬ 
ing,  and  Construction  wiU  have  similar  checklists  of  requirements.  The  review 
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of  applicable  experiences  contained  in  the  OKBank  system  should  be  added  to 
the  checkhst  of  each  of  these  major  divisions  as  an  item  to  be  completed. 


Conclusion 

This  investigation  has  indicated  that  one  way  for  an  organization  to  improve  its 
performance  is  for  the  organization  to  learn  from  the  knowledge  and  experiences 
of  its  members.  This  practice  is  even  truer  for  organizations  responsible  for  civil 
works  projects,  which  are  usually  large  and  complicated.  Each  phase  of  the  life 
cycle  of  these  projects  has  unique  requirements  and  involves  many  stakeholders. 
In  addition,  many  civil  works  organizations  have  heavily  relied  upon  the  experi¬ 
ences  and  knowledge  of  the  veteran  employees  for  maintaining  the  organization’s 
success.  Recently,  budget  reductions  have  forced  these  organizations  to  lay  off 
many  veteran  employees  and  more  are  leaving  voluntarily.  For  the  orgamzation 
to  effectively  learn  from  all  of  its  members,  especially  from  veteran  employees 
while  they  are  still  employed,  a  systematic  approach  for  capturing,  storing,  and 
retrieving  knowledge  is  required.  This  research  suggested  that  an  automated 
system  is  the  best  mechanism  for  use  in  this  approach. 

It  would  be  a  big  challenge  to  develop  an  automated  system  to  capture  and  share 
the  organizational  knowledge  from  all  project  participants,  across  multiple 
disciplines,  and  throughout  all  phases  of  the  project  life  cycle.  Such  a  system 
should  be  able  to  capture,  store,  and  allow  for  retrieval  of  knowledge  at  multiple 
access  points  in  time  and  space.  Fortunately,  the  Internet  is  available.  The 
Internet  and  related  technologies  have  made  the  development  of  the  OKBank 
prototype  system  possible.  The  OKBank  prototype  system  will  allow  organi¬ 
zations  such  as  the  Vicksburg  District  to  do  more  with  less  by  tapping  into  one  of 
its  most  vital  resources,  the  organizational  knowledge  bank. 

Without  question,  organizations  such  as  the  Wcksburg  District  will  benefit  from 
the  OKBank  system.  The  only  question  is  the  cost-benefit  ratio  of  such  a  system. 
In  the  past,  many  similar  systems  have  been  developed.  Most  of  them,  however, 
operated  on  standalone  platforms.  The  high  cost  per  user  of  these  standalone 
systems  has  discouraged  many  org£tnizations  from  implementing  them.  The 
.  Internet  platform  has  solved  some  of  these  cost  concerns.  The  Internet  allows 
the  system  to  be  used  by  as  many  persons  as  allowed  by  the  organization  without 
any  additional  software  cost  per  user.  There  will  be  no  updates  beyond  those 
provided  to  the  operating  system.  The  training  cost  will  be  minimal  because 
very  little  training  is  required  to  use  the  OKBank  system.  Best  of  all,  organiza¬ 
tions  such  as  the  Vicksburg  District  can  start  reaping  the  benefits  of  the 
OKBank  system  immediately. 
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Appendix  A:  Sample  Questionnaire 

Project  Development  (Planning  &  Programming) 

Name: _ Organization _ Phone  No. _ 

Purpose:  The  questions  below  are  designed  to  capture  some  of  the  organizational 
experiences  on  the  Red  River  Levees  project  by  interviewing  key  players  in  all 
phases  of  the  project  life  cycle.  The  questions  will  be  slightly  different  for  each 
phase  of  the  project. 

1.  When  planning  and  programming  for  Levee  projects  on  Red  River,  what  are 
the  few  problems  (repetitive  or  major  problems)  that  you  or  your  office  have 
encountered,  and  that  you  would  not  weint  to  see  happen  again?  Are  there 
positive  experiences  or  success  stories  that  you  would  like  to  share? 

Examples:  problems  with  site  analysis,  problems  with  the  overall  project 
schedule,  problems  with  the  landowners  or  with  the  right  of  ways,  what  items 
are  often  forgotten  in  preliminary  project  scope,  what  items  are  often  needed  but 
usually  missed  when  project  documentation/need  statements  are  developed. 

Examples  of  good  work  practices:  where  to  obtain  the  best  soil  for  the  levee, 
when  is  the  best  time  for  turfing,  etc. 

Situation 

background: 


solution: 
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references: 


2.  What  information/data  would  you  like  to  see  in  the  system  that  might  benefit 
you? 


3.  Other  remarks: 
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